I'll reopen this when I work on more examples again.

We can get around manually dropping things by ordering the members in the struct definitions in the order we want to drop them. I feel, however, that manually drop helps document the order in which you should be dropping things. I think you'll agree that It would be annoying if changing the order of the members in a struct caused bugs.

As for takeable, no. The hal destroy functions want ownership of the struct members & drop only gets an &mut of the structs.

We can get around manually dropping things by ordering the members in the struct definitions in the order we want to drop them.

Do you really have to drop things in a specific order with HAL? AFAIK, Vulkan says destruction order can be arbitrary.

Other than the swapchain, no. I removed all the ManuallyDrops and just made the swapchain Takeable.

Thank you!
I'm still not sure we need takeable_option magic though. Would the code be much worse if it had a few regular Option members of structs? In the worst case, we'll have something like as_mut().unwrap() in a place or two, but using a standard construct (Option) is way friendlier.

@kvark You can compare the two versions and see which you prefer. I personally like Takeable (else I wouldn't have made it).

@zegentzy thank you, looks great! Let's fix the CI issues and get this merged.

@kvark Done.

Build succeeded

• continuous-integration/travis-ci/push
• continuous-integration/appveyor/branch